connect: don't answer our own cluster update with another state update - #1741

While an active Connect device, librespot answers its own cluster update with another state
update, and the reply comes back as another cluster update. The result is a state-update loop
that runs at the round-trip period and only stops when Spotify answers 429 Too Many Requests.

The loop

Every notify() PUTs the device state. Spotify pushes the resulting cluster update back down
the dealer socket — including the one our own PUT just caused — and handle_cluster_update
sets update_state = true for any update that arrives while we are active, without checking
where it came from:

} else if self.connect_state.is_active() {
    // fixme: workaround fix, because of missing information why it behaves like it does
    //  background: when another device sends a connect-state update, some player's position de-syncs
    //  tried: providing session_id, playback_id, track-metadata "track_player"
    self.update_state = true;
}

That schedules another notify() after UPDATE_STATE_DELAY, which PUTs, which echoes. Traced
against a real session it runs at a median of 418 ms:

10:20:33.829  cluster update: Ok(DEVICE_STATE_CHANGED) from spotifly_53879, active device: spotifly_53879
10:20:34.110  Requesting …/connect-state/v1/devices/spotifly_53879
10:20:34.249  cluster update: Ok(DEVICE_STATE_CHANGED) from spotifly_53879, active device: spotifly_53879
10:20:34.528  Requesting …/connect-state/v1/devices/spotifly_53879
10:20:34.673  cluster update: Ok(DEVICE_STATE_CHANGED) from spotifly_53879, active device: spotifly_53879
10:20:34.945  Requesting …/connect-state/v1/devices/spotifly_53879

The loop has no brake of its own. Across two captured sessions, every burst ended in a
429 — five out of five. The only gaps not preceded by one are the idle stretch before playback
starts. The requests it burns are the device-state PUTs, so the ones dropped are the ones that
tell Spotify the device exists and what it is playing.

The change

ClusterUpdate.devices_that_changed already carries what is needed to tell the cases apart,
and handle_cluster_update already logs it a few lines above. Skip the update when it names
only us:

let is_own_echo = matches!(reason, Ok(ClusterUpdateReason::DEVICE_STATE_CHANGED))
    && matches!(
        cluster_update.devices_that_changed.as_slice(),
        [changed_device_id] if changed_device_id == self.session.device_id()
    );

The fixme workaround stays. The comment records that session id, playback id and track
metadata were all tried against the underlying de-sync and none helped, which is evidence
against removing it. Anything that is not our own echo still reaches it.

Kept deliberately narrow, in two ways that matter:

• Reason-gated. "Names only us" implies "caused by us" for a state change, not for a
  device appearing, disappearing, or changing volume. Without this gate the change swallows a
  DEVICE_VOLUME_CHANGED echo that should reach the workaround — which happened in testing,
  so this is not hypothetical.
• Exact single-element match. An empty list, or one naming this device alongside another,
  falls through to the workaround unchanged.

Commands from other devices were never affected either way: those arrive on the connect-state
request stream and set update_state from handle_connect_state_request.

Verification

Measured on macOS against a real Spotify account, comparing device-state PUTs in the 60
seconds after PlayerEvent::Playing:

Across a whole 2m38s session after the change: 17 device-state PUTs, 11 echoes suppressed, no
429 in a scenario that produced them on every previous run.

Legitimate state updates still go out — the count is small, not zero.

The workaround's case still works. With a second device sending pause, resume and volume
while librespot was the active device, the position did not de-sync:

05:18:35.799  handling: 'endpoint: pause' from c077d34a96…
05:18:35.848  PlayerEvent::Paused  at 112197ms
05:18:41.212  handling: 'endpoint: resume' from c077d34a96…
05:18:41.213  PlayerEvent::Playing at 112197ms

Paused and resumed on the same millisecond, held flat across the state updates in between, and
tracked real time correctly afterwards. Volume propagated in both directions.

On the premise

The filter assumes an echo names only the device that caused it. Checked against 449 cluster
updates captured from real sessions before writing anything: not one named more than a single
device. Updates from other devices do appear while active, which is what the workaround
branch still handles.

Checks

cargo fmt --all -- --check, cargo build, cargo clippy --all-targets (zero warnings) and
cargo test --workspace (23 passed) all clean. Note that connect/ has no tests near
spirc.rs, so those are a don't-regress gate rather than coverage of this change; the
measurements above are the verification.

🤖 Generated with Claude Code